Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-086

Text File | 1995-12-31 | 99KB | 2,647 lines

C.S.M.P. Digest             Tue, 28 Feb 95       Volume 3 : Issue 86

Today's Topics:

        BUG Universal Headers:CursorDevices.h
        Custom QT movie controllers
        Drawing on a PicHandle?
        How to lineto() with a colored line?
        OpenDoc. Hunh?
        PICT file to-from GWorld
        Question for Thread Manager gurus



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                                Sends you a summary of commands
    subscribe csmp-digest Your Name     Adds you to the mailing list
    signoff csmp-digest                 Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail].

-------------------------------------------------------

>From [e-mail] (David Phillip Oster)
Subject: BUG Universal Headers:CursorDevices.h
Date: Wed, 8 Feb 1995 19:55:53 GMT
Organization: Netcom Online Communications Services (408-241-9760 login: guest)


I'm still using the universal headers that came on the Code Warrior 5 CD,
I'm told there is a newer set out on an ETO disk, but I don't have access
to it. Tell me, is the following fixed:

Hardware Technote 1:ADB The Untold Story : Space Aliens Ate My Mouse
says that:
Function CrsrDevButtons(ourDevice: CrsrDevRec;
                        buttons: Char):OSErr;
Function CrsrDevButtonOp(ourDevice: CrsrDevRec; btnNo: Integer;
                         opCode: Integer; data: LongInt):OSErr;
Function CrsrDevSetButtons(ourDevice: CrsrDevRec;
                           numButtons: Integer):OSErr;
Function CrsrDevSetAcceleration(ourDevice: CrsrDevRec,
                                      acceleration: Fixed):OSErr;
Function CrsrDevDoubleTime(ourDevice: CrsrDevRec;
                           duration: LongInt):OSErr;
Function CrsrDevUnitsPerInch(ourDevice: CrsrDevRec;
                             resolution: Fixed):OSErr;

But "Universal Headers:CursorDevices.h" says:

extern pascal OSErr CrsrDevButtons(CrsrDevicePtr ourDevice)
 THREEWORDINLINE(0x303C, 0x0003, 0xAADB);
extern pascal OSErr CrsrDevButtonOp(CrsrDevicePtr ourDevice)
 THREEWORDINLINE(0x303C, 0x0006, 0xAADB);
extern pascal OSErr CrsrDevSetButtons(CrsrDevicePtr ourDevice)
 THREEWORDINLINE(0x303C, 0x0007, 0xAADB);
extern pascal OSErr CrsrDevSetAcceleration(CrsrDevicePtr ourDevice)
 THREEWORDINLINE(0x303C, 0x0008, 0xAADB);
extern pascal OSErr CrsrDevDoubleTime(CrsrDevicePtr ourDevice)
 THREEWORDINLINE(0x303C, 0x0009, 0xAADB);
extern pascal OSErr CrsrDevUnitsPerInch(CrsrDevicePtr ourDevice)
 THREEWORDINLINE(0x303C, 0x000A, 0xAADB);


Obviously, the latter is wrong and should be fixed. I don't know how
to report this to Apple. I don't know if it has already been fixed.
--
- ------- <mail-to:[e-mail]> ----------
There is no sight finer than that of the planet Earth in your rearview mirror.



+++++++++++++++++++++++++++

>From harun@PROBLEM_WITH_INEWS_DOMAIN_FILE (Scheutzow)
Date: 11 Feb 1995 09:11:02 GMT
Organization: I need to put my ORGANIZATION here.

Yes, CursorDevices.h is WRONG. But it is "auto-created by the interfacer tool"
:-(

Regards, [e-mail]


---------------------------

>From [e-mail] (GBolsinga)
Subject: Custom QT movie controllers
Date: 3 Feb 1995 17:22:43 -0500
Organization: America Online, Inc. (1-800-827-6364)

Has anybody written one?  I am writing one that will be used only in our
QT CD-ROM.  I thought that I'd make a a locally defined component ('thng'
resource in my app's resource fork) and "target" the standard movie
controller, since all I really need is a playback controller.  But now I
am
having doubts about doing it this way since in _develop 18_, Peter
Hoddie's
article talks about how the standard movie controller will definitely
change how it acts in the future.  These are things that I can't predict,
and
thus, will have to rewrite in the future to 'overload' those I don't want.
So, I don't think I want to 'target' the standard movie controller.

So, have you written one?  How did you do it? Did you target the standard
controller?  Did you make your own controller component?  If you did,
did you implement all the code's that the standard movie controller can
do? (editing, badges, un-attaching, etc.)  If you made your own, not as a
component, did it work nicely? By this I mean- Apple doesn't seem to
reccommend doing it this way.  What did you find?  Anybody from the
Adobe Premeire team that can tell me the technique you used?

Thanks
-greg
Greg Bolsinga
MPI Multimedia

+++++++++++++++++++++++++++

>From [e-mail] (Kent Sandvik)
Date: Tue, 14 Feb 1995 23:15:43 -0800
Organization: Apple Computer, Inc. Developer Technical Support

In article <3guabj$[e-mail]>, [e-mail]
(GBolsinga) wrote:
> So, have you written one?  How did you do it? Did you target the standard
> controller?  Did you make your own controller component?  If you did,
> did you implement all the code's that the standard movie controller can
> do? (editing, badges, un-attaching, etc.)  If you made your own, not as a
> component, did it work nicely? By this I mean- Apple doesn't seem to
> reccommend doing it this way.  What did you find?  Anybody from the
> Adobe Premeire team that can tell me the technique you used?

The nice thing with the built-in movie controller is that Apple has the
headache of maintaining it forever and ever. In addition we have added all
kinds of nifty features to the movie controllers, such as drag-and-drop
support, palette handling. Expect similar things to happen later. Thirdly,
using a movie controller makes life easier when moving code to the
QuickTime for Windows side, as the primary API for QTW is a movie
controller.

You could install a plentiful of functions that control a hidden movie
controller from your own controlling CDEF. This is for instance how AMK
just now handles their specific movie controllers. Works really well with
QTW.

Note also that the Apple provided movie controller does a lot of magic
inside GWorlds to make the controls update smoothly, so if you want to
provide a similar user experience you have to make sure your controller
elements look and behave well.

Cheers, Kent

--
Kent Sandvik   [e-mail]   New Media Analyst/Programmer
Private activities on Internet.

---------------------------

>From [e-mail] (Scott Gruby)
Subject: Drawing on a PicHandle?
Date: Mon, 13 Feb 1995 22:52:12 -0800
Organization: Harvey Mudd College

Here's the problem: I've grabbed a PICT using the QuickTime sequence
grabber commands and now I have a PicHandle. However, I now want to draw
on top of the PicHandle. Is this possible? If so could someone point me in
the right direction? What I'm going to do with the PicHandle is save it or
write it to the clipboard, so I've tried SetPort((GrafPtr)*myPicHandle)
and then drawing, but this is obviously incorrect. Am I correct that
PicHandle is a handle of a union of a short and a Rect? Where does it
contain the actual PICT data?

Thanks.

--
Scott Allen Gruby                         ([e-mail])

+++++++++++++++++++++++++++

>From [e-mail] (ALTURA)
Date: 14 Feb 1995 13:09:47 -0500
Organization: America Online, Inc. (1-800-827-6364)

> I've tried SetPort((GrafPtr)*myPicHandle)
> and then drawing, but this is obviously incorrect. Am I correct that
> PicHandle is a handle of a union of a short and a Rect? Where does it
> contain the actual PICT data?

You definitiely don't want to try and set the port with a PicHandle.  A
PicHandle is a variable length structure.  The first two bytes are the
length of the picture; however, this is essentially ignored in the current
system as PICTs can be >32K.  Next comes a Rect which is the bounding box
for the PICT.  After that, is the variable length PICT data (documented in
IM V).  To draw it, try this:

void draw_my_picture(PicHandle pic_h, short draw_offset_h, short
draw_offset_v)
{
  Rect     frame_r = (**pic_h).picFrame;
  OffsetRect(&frame_r, draw_offset_h - frame_r.left, draw_offset_v -
frame_r.top);
  DrawPicture(pic_h, &frame_r);   // MacOS call to draw a picture
}

-Jordan

+++++++++++++++++++++++++++

>From [e-mail] (bob gulian)
Date: 14 Feb 1995 19:13:11 GMT
Organization: CRL Dialup Internet Access

In article <[e-mail]>,
[e-mail] (Scott Gruby) wrote:

> Here's the problem: I've grabbed a PICT using the QuickTime sequence
> grabber commands and now I have a PicHandle. However, I now want to draw
> on top of the PicHandle. Is this possible? If so could someone point me in
> the right direction? What I'm going to do with the PicHandle is save it or
> write it to the clipboard, so I've tried SetPort((GrafPtr)*myPicHandle)
> and then drawing, but this is obviously incorrect. Am I correct that
> PicHandle is a handle of a union of a short and a Rect? Where does it
> contain the actual PICT data?
>
> Thanks.
>
> --
> Scott Allen Gruby                         ([e-mail])


Here's a general synopsis of what you want to do with your PicHandle;

SetPort( WhateverPort_you_want_to_draw_in);
ClipRect  (&(*yourPicHandle)->picFrame);

PicHandle newPH = OpenPicture(&(*yourPicHandle)->picFrame);
DrawPicture(yourPicHandle,&(*yourPicHandle)->picFrame);

// Now draw your new stuff

ClosePicture();


newPh will now contain your "grabbed" pict with the new stuff drawn over it.

Hope this helps.

BG

---------------------------

>From [e-mail] (John  Boswell)
Subject: How to lineto() with a colored line?
Date: 11 Feb 1995 21:48:45 GMT
Organization: Dartmouth College, Hanover, NH, USA

Hi,
        Just a quick question:  I've got some simple graphics routines
that I use for a quick plot of the results of my calculations.  The
routines just use MoveTo() and LineTo() to draw the plots.  I'd like
to be able to overlay plots using different colored lines.  Is there an
easy toolbox call for this?  So far I've only figured out how to change
the pattern- but that's not much help as the lines I draw are thin (1
pixel?).
        Thanks a bunch for any pointers...

-John Boswell

--
****************************************************************************
Dr. John Boswell                                [e-mail]
Dept. of Chemistry, Biochemistry and Molecular Biology
Oregon Graduate Institute, Portland, OR         503-690-1086
>From [e-mail] (John  Boswell)
Subject: How to lineto() with a colored line?
Date: 11 Feb 1995 22:05:04 GMT
Organization: Dartmouth College, Hanover, NH, USA

[ Article crossposted from comp.sys.mac.programmer.help ]
[ Author was John  Boswell ]
[ Posted on 11 Feb 1995 21:48:45 GMT ]

Hi,
        Just a quick question:  I've got some simple graphics routines
that I use for a quick plot of the results of my calculations.  The
routines just use MoveTo() and LineTo() to draw the plots.  I'd like
to be able to overlay plots using different colored lines.  Is there an
easy toolbox call for this?  So far I've only figured out how to change
the pattern- but that's not much help as the lines I draw are thin (1
pixel?).
        Thanks a bunch for any pointers...

-John Boswell

--
****************************************************************************
Dr. John Boswell                                [e-mail]
Dept. of Chemistry, Biochemistry and Molecular Biology
Oregon Graduate Institute, Portland, OR         503-690-1086

--
****************************************************************************
Dr. John Boswell                                [e-mail]
Dept. of Chemistry, Biochemistry and Molecular Biology
Oregon Graduate Institute, Portland, OR         503-690-1086

+++++++++++++++++++++++++++

>From [e-mail] (Ken Long)
Date: Sun, 12 Feb 1995 18:29:29 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

John  Boswell ([e-mail]) wrote:
: Hi,
:       Just a quick question:  I've got some simple graphics routines
: that I use for a quick plot of the results of my calculations.  The
: routines just use MoveTo() and LineTo() to draw the plots.  I'd like
: to be able to overlay plots using different colored lines.  Is there an
: easy toolbox call for this?  So far I've only figured out how to change
: the pattern- but that's not much help as the lines I draw are thin (1
: pixel?).

Leave the pattern at default (solid).

If this program is for your use only, on a color Mac, then you won't need
a color checking routine.

The default Mac background color is white.  When you erase a rectangle,
it will erase to white unless you say different, so that part's okay.
It's the forecolor you want to change.

With that, there are two options - use the cyan, red, green, blue, etc.
ro specify a specific RGB value.

In the first one, *just before* wherever your line coords get new values,
put in a:

ForeColor (redColor); // Or whatever color.

and a:

ForeColor (blackColor); // When you're all done (may not be necessary
                        // but it can't hurt to make sure things are put
                        // back like you found them).

The alternatice, specification route is a little more complicated, but
not much.

Use:

SetColor (short red, short, green, short blue)
{
    RGBColor hue;

    hue.red = red;
    hue.green = green;
    hue.blue = blue;

    RGBForeColor (&hue);
}

A call to this, passing along the three values, will set the RGB
forecolor on the fly (providing you're even drawing a fly  : ).

SetColor (0xffff, 0x0000, 0x0000);

will set the forecolor to red (maximum).  You can also do:

SetColor (65535, 0, 0); for less typing and the same result.  As you can
see, you are passing a set of 3 values for the corresponding R, G and B
values which get set into the RGBColor structure initialized (each time)
in SetColor.  These values can be anything from 0 to 65535 each.  But, I
believe, they will be rounded to the closest sustem 'clut' color to your
choice, in 256 mode.

If you went:

SetColor (Random (), Random (), Random ());  Then the colors would be set
on a "what you see is what you get"  (WYSIWYG) basis.  Or "TWYGALI" (take
what you get, and like it), as my dad used to say.

So, you'd use "SetColor" just before your MoveTo/LineTo coordinate values
changed.  Then do a ForeColor (blackColor); before the program finished
(just to make sure - with fonts, sometimes the setting gets passed to the
parameter RAM on exit, a not-too-cool situation).

Sometimes, in some programs, I'd set the RGB forcolor and have it not
work, so I'd change it to the backcolor and it would work.  Some sort of
inversion took place without me spotting it.

One thing about coloring lines is that they have to be deliberately
erased.  In Dave Mark's "FlyingLine" (and similar programs) they run just
fine in B/W.  But then you go trying to put RGB into them and now the
lines don't erase, and the drawing "piles up".  There are ways to handle
this.

Draw the line in color, delay a short time so it sticks around long
enough to enjoy, then redraw the line, to the same coord's, with the
background color, is one way.  Another is to draw them and leave their
values in a queue containing a number of iterations, then do the redraw
(in BG color) at the oldest end of the queue (ala Moire, and ZoomIdle).

Does any of this help?  Or do I taste toe jam (from having
"foot-in-mouth" disease)?

-Ken-

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Sun, 12 Feb 1995 19:37:26 -0800
Organization: Internet for the Olympic Peninsula

In article <[e-mail]>, [e-mail] (Ken Long) wrote:

> If this program is for your use only, on a color Mac, then you won't need
> a color checking routine.

For the old color model (cyan, et al) and ForeColor, no color check is
required at all.  (Unless one want's to do something else in grayscale or
1 bit dept).  That stuff was in QuickDraw on every released Mac.

[I had some MacForth apps which used them...when the Mac II came out, I
had to ask someone with a Mac II whether the color showed up as expected:
it did.]

   --John

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
       Isn't C fun?
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Joe Michels)
Date: Mon, 13 Feb 1995 14:34:26 -0600
Organization: QMS Inc.

In article <3hjcag$[e-mail]>,
[e-mail] (John  Boswell) wrote:

> [ Article crossposted from comp.sys.mac.programmer.help ]
> [ Author was John  Boswell ]
> [ Posted on 11 Feb 1995 21:48:45 GMT ]
>
> Hi,
>         Just a quick question:  I've got some simple graphics routines
> that I use for a quick plot of the results of my calculations.  The
> routines just use MoveTo() and LineTo() to draw the plots.  I'd like
> to be able to overlay plots using different colored lines.  Is there an
> easy toolbox call for this?  So far I've only figured out how to change
> the pattern- but that's not much help as the lines I draw are thin (1
> pixel?).
>         Thanks a bunch for any pointers...
>
> -John Boswell
>
Look at RGBForeColor, that should give you plenty of color control.
Joe

---------------------------

>From [e-mail] (Dan Lakeland)
Subject: OpenDoc. Hunh?
Date: 14 Jan 95 17:57:43 GMT
Organization: Iowa State University, Ames, Iowa

Well, I just got ahold of the excellent MacTech magazine featuring
OpenDoc and OLE CD's. I'm impressed, but I can't help but say HUNH?

First off. What about 68K programmers?? Everything in the articles
involved PPC DLL's.

I haven't had a chance to look at the CD's yet, but could someone maybe
give me a hint as to what it is that really launches a document? Is
OpenDoc a program (shell for your parts) as well as a standard?

Does SOM and OpenDoc work with Metrowerks CW Bronze? (it seems from the
articles to rely on DLL's as I said earlier, I'm all for PPC but I don't
have one yet...)

Is OpenDoc really a set of SOM objects which implement the standard? If
so, at what level do I interact with SOM?

As you can see, lots of questions... Perhaps I'll answer SOM myself by
looking at the CD, but in the meantime, if anyone has SOM answers I'd be
more than happy to question them :)
--
Daniel Lakeland: Macintosh Hacker, Mathematics Major, NRA Member.
If you want peace, work for justice. If you want prosperity, work for
free markets, if you want to write Mac software, you're outta luck.

+++++++++++++++++++++++++++

>From [e-mail] (Dan Lakeland)
Date: 14 Jan 95 21:39:42 GMT
Organization: Iowa State University, Ames, Iowa

In <[e-mail]> [e-mail] (Dan Lakeland) writes:

Having looked at the CD, I can now answer a few of my questions, and ask
a new one.

>First off. What about 68K programmers?? Everything in the articles
>involved PPC DLL's.

It includes a 68k version of the code frag manager so you can
(magically) use DLL's on the 68K (HOORAY!)

>I haven't had a chance to look at the CD's yet, but could someone maybe
>give me a hint as to what it is that really launches a document? Is
>OpenDoc a program (shell for your parts) as well as a standard?

Yes, open-doc is itself a program, which sort of "shells" your parts.

>Does SOM and OpenDoc work with Metrowerks CW Bronze? (it seems from the
>articles to rely on DLL's as I said earlier, I'm all for PPC but I don't
>have one yet...)

Now, here's my new question, having installed CW5 I looked at the
"what's new" and saw "support for OpenDoc" well, I want to know how to
develop parts in CW5 on the 68k. All the docs I've seen so-far involve
the PPC version. Apparently Bronze doesn't like to make DLL's??

--
Daniel Lakeland: Macintosh Hacker, Mathematics Major, NRA Member.
If you want peace, work for justice. If you want prosperity, work for
free markets, if you want to write Mac software, you're outta luck.

+++++++++++++++++++++++++++

>From [e-mail] (Paul Lalonde)
Date: Sat, 14 Jan 1995 23:59:49 -0400
Organization: McGill University School of Architecture

In article <[e-mail]>, [e-mail]
(Dan Lakeland) wrote:

> Now, here's my new question, having installed CW5 I looked at the
> "what's new" and saw "support for OpenDoc" well, I want to know how to
> develop parts in CW5 on the 68k. All the docs I've seen so-far involve
> the PPC version. Apparently Bronze doesn't like to make DLL's??

The answer is:  you can't, because the 68K compiler doesn't support
the 68K version of the Code Fragment Manager.  Watch for it in CW6.
The PowerPC compiler, of course, can be used to write PowerPC OpenDoc
part handlers.


Paul Lalonde
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Steve Zellers)
Date: Sun, 15 Jan 1995 01:26:24 -0800
Organization: BasilSoft, Inc.

In article <[e-mail]>, [e-mail]
(Dan Lakeland) wrote:

> It includes a 68k version of the code frag manager so you can
> (magically) use DLL's on the 68K (HOORAY!)

This, along with:

> Now, here's my new question, having installed CW5 I looked at the
> "what's new" and saw "support for OpenDoc" well, I want to know how to
> develop parts in CW5 on the 68k. All the docs I've seen so-far involve
> the PPC version. Apparently Bronze doesn't like to make DLL's??

The answer is: you must use the (trial size?) version of MPW included on
the CD.  The only compiler that can generate 68k CFM libraries is a hacked
version of the Symantec C++ compiler, which is included on the CD.

THey claim that to compile requires 30 meg of memory (!!!!) (real or
virtual) but I didn't have any such problem compiling simple CFM programs
(the ModApp example)  So you should be OK with that compiler.  (But you
must run it under MPW)

Because of this, you can't yet truly build SOM based code on the 68k mac
using CodeWarrior.  YOu can use CW to generate it for the PPC, however.

--smz

+++++++++++++++++++++++++++

>From John Kawakami <[e-mail]>
Date: Mon, 16 Jan 1995 20:08:37 GMT
Organization: Xplain Corp.

In article <3fdk99$[e-mail]>, [e-mail] wrote:

> In article <[e-mail]>, [e-mail]
(Dan Lakeland) writes:
> |> Well, I just got ahold of the excellent MacTech magazine featuring
> |> OpenDoc and OLE CD's. I'm impressed, but I can't help but say HUNH?
> |>
>
> Are this CDs part of a MacTech issue? Which issue? Where can I get it from?
>
> Martin

Before I tell you how to subscribe, I must extend my thanks to all the
answers people provided to the Mr. Lakeland regarding the CD.  And (yet
another) thanks to Apple and Microsoft for making the discs available.

The developer CDs are included in the January 1995 issue of MacTech.  This
should be on the newsstand as you read this message.

To subscribe to MacTech, check the ftp site below for a subscription form
(that has a discount price).  [The form is also available on the
commercial online services.]  For other info about MacTech, email to
[e-mail].

John Kawakami
Editorial Assistant
MacTech Magazine
- -MacTech Magazine--------------------------------------------------
PO Box 250055, Los Angeles, CA 90025, 310-575-4343, Fax:[phone]
For more info, anonymous ftp: ftp.netcom.com, cd to /pub/xp/xplain
email to the following @xplain.com : custservice, editorial,
adsales, marketing, accounting, pressreleases,
progchallenge, publisher, info

+++++++++++++++++++++++++++

>From [e-mail] (Julian Harris)
Date: Wed, 18 Jan 1995 08:58:24 +1300
Organization: Computer Science Department, UA

In article <[e-mail]>, John
Kawakami <[e-mail]> wrote:

> In article <3fdk99$[e-mail]>, [e-mail] wrote:
>
> > In article <[e-mail]>, [e-mail]
> (Dan Lakeland) writes:
> > |> Well, I just got ahold of the excellent MacTech magazine featuring
> > |> OpenDoc and OLE CD's. I'm impressed, but I can't help but say HUNH?
> > |>
> >
> > Are this CDs part of a MacTech issue? Which issue? Where can I get it from?
> >
> > Martin
>
> Before I tell you how to subscribe, I must extend my thanks to all the
> answers people provided to the Mr. Lakeland regarding the CD.  And (yet
> another) thanks to Apple and Microsoft for making the discs available.
>
> The developer CDs are included in the January 1995 issue of MacTech.  This
> should be on the newsstand as you read this message.

While we're on the OpenDoc thread, how many of the part editors on the
OpenDoc CD did people get to even _run_? I got about 4. None of the 'Third
Party' ones seemed to want to work. I was running System 7.5 with the
required 4 extensions (MixedModeINIT, CFM68K, Apple Event Manager 1.0.3,
MEO). Macsbug kept on coming up with 'couldn't load part editor' even
though all the part editors were in the 'Editors' folder.

Any clues? Thanks in advance.
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
Microsoft is not the answer.                    >  Julian Harris, Programmer   >
Microsoft is the question.                     >  Comp. Sci. Dept.     x8915  >
                                              >  The University of Auckland  >
NO is the answer.                            >  [e-mail]    >

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Tue, 17 Jan 1995 20:48:47 -0800
Organization: Internet for the Olympic Peninsula

In article <[e-mail]>,
[e-mail] (Julian Harris) wrote:

> While we're on the OpenDoc thread, how many of the part editors on the
> OpenDoc CD did people get to even _run_? I got about 4. None of the 'Third
> Party' ones seemed to want to work. I was running System 7.5 with the
> required 4 extensions (MixedModeINIT, CFM68K, Apple Event Manager 1.0.3,
> MEO). Macsbug kept on coming up with 'couldn't load part editor' even
> though all the part editors were in the 'Editors' folder.

One thing that does work (at least on PowerMac) is to embed the (analog)
clock part in the puzzle.  Kind of weird to see and manipulate disembodied
pieces of clock, with pieces of second hand passing through them
(appropriately).

Unfortunately, I don't see a "significant profit opportunity" in that.
   --John

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
       Isn't C fun?
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Rick Wong)
Date: Tue, 17 Jan 1995 18:47:39 -0700
Organization: Stanford University

In article <[e-mail]>,
[e-mail] (Julian Harris) wrote:
: While we're on the OpenDoc thread, how many of the part editors on the
: OpenDoc CD did people get to even _run_? I got about 4. None of the 'Third
: Party' ones seemed to want to work. I was running System 7.5 with the
: required 4 extensions (MixedModeINIT, CFM68K, Apple Event Manager 1.0.3,
: MEO). Macsbug kept on coming up with 'couldn't load part editor' even
: though all the part editors were in the 'Editors' folder.

>From the Third Party Parts folder's Read Me file:

<quote>
These are some sample part editors developed by a number of people not
directly on the OpenDoc(tm) team.  These sample part editors are here
for those that want to take a look at some of the more innovative part
editors that have been developed using OpenDoc.  Please note that these
part editors are not bug free.  In fact, they are quite unstable and
most will only run on Power Macintoshes.  However, that said, there
are some interesting samples to try out.

Many of the part editors in this folder were developed at the OpenDoc
Coding Kitchen held in Stockholm, Sweden in November 1994.  Developers
with little or no OpenDoc experience were able to convert their existing
Macintosh applications to OpenDoc part editors in just three days.
This should be encouraging to those of you that have legacy code that
you are considering migrating to OpenDoc part editors and containers.
We should mention that all of the demo parts you see in this folder
are PowerPC parts, and will not run on 68K Macintoshes.
</quote>

Rick "I see many Republicans . . . I see much meat" Wong

+++++++++++++++++++++++++++

>From [e-mail] (John Raley)
Date: 18 Jan 1995 22:26:18 -0500
Organization: CS Dept, VA Tech, Blacksburg, VA  24061


Was it just me, or did OpenDoc seem unstable as hell?  I'm not talking
about having the go-round with the Third-party stuff not running on a
68K mac - I'm talking about the sample parts crashing and hanging for
no apparant reason.

I'm all for stopping an MS monopoly in this new area, but it's gonna
take more than we've got right now.

John

+++++++++++++++++++++++++++

>From [e-mail] (Herb Voth)
Date: 19 Jan 95 12:01:55 GMT
Organization: Simon Fraser University

[e-mail] (John W. Baxter) writes:

>One thing that does work (at least on PowerMac) is to embed the (analog)
>clock part in the puzzle.  Kind of weird to see and manipulate disembodied
>pieces of clock, with pieces of second hand passing through them
>(appropriately).

>Unfortunately, I don't see a "significant profit opportunity" in that.
>   --John

Isn't this the problem with OpenDoc, though? I think it is a great
concept whose time has come, but parts won't make money - applications
that can use parts will.

I think it will be a great way for things like TextEdit to be
'contained' in an application. If you support one, you support them
all is a creed that will make me happy... if it works out that way.

-Randall


+++++++++++++++++++++++++++

>From [e-mail] (Gavin Eadie)
Date: Thu, 19 Jan 1995 12:24:52 -0500
Organization: U of Michigan

In article <3fkm4q$[e-mail]>, [e-mail] (John Raley) wrote:

> Was it just me, or did OpenDoc seem unstable as hell?  I'm not talking
> about having the go-round with the Third-party stuff not running on a
> 68K mac - I'm talking about the sample parts crashing and hanging for
> no apparant reason.
>
> I'm all for stopping an MS monopoly in this new area, but it's gonna
> take more than we've got right now.


    Jeez ... People complain they don't have access to early test versions
of new technology and then they complain when they get it that it doesn't
behave like final product.  The beta OpenDoc release is for developers who
want to get their stuff ready for OpenDoc, it's not for people to use.
Give me a break - take it or leave it but cut the whining.
--
Gavin Eadie // U of Michigan.
            // Ramsay Consulting.

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Fri, 20 Jan 1995 09:41:37 +0800
Organization: Department of Computer Science, University of Western Australia

In article <3fkm4q$[e-mail]>, [e-mail] (John Raley) wrote:

>Was it just me, or did OpenDoc seem unstable as hell?

No it's not just you.  However the OpenDoc on the MacTech CD was pre-beta
and therefore it's allowed to have lots of bugs.  If you experienced any
System 7 pre-betas you'll know what I mean (:

Share and Enjoy.
--
Quinn "The Eskimo!"     "Ah, so that's the secret,
                         if only Captain Bipto had known."

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Thu, 19 Jan 1995 19:11:18 -0800
Organization: Internet for the Olympic Peninsula

In article <[e-mail]>, [e-mail] (Herb Voth) wrote:

> [e-mail] (John W. Baxter) writes:
>
> >One thing that does work (at least on PowerMac) is to embed the (analog)
> >clock part in the puzzle.  Kind of weird to see and manipulate disembodied
> >pieces of clock, with pieces of second hand passing through them
> >(appropriately).
>
> >Unfortunately, I don't see a "significant profit opportunity" in that.
> >   --John
>
> Isn't this the problem with OpenDoc, though? I think it is a great
> concept whose time has come, but parts won't make money - applications
> that can use parts will.

Sorry, I didn't write that clearly...I meant I don't see a significant
profit opportunity in disjoint second hands wandering correctly through
the puzzle part.

I don't think there's much room left for the really small shop outside
tightly confined niches EXCEPT parts...apps have become to hard to write.

   --John

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
       Isn't C fun?
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Andrew Geweke)
Date: Fri, 20 Jan 1995 00:25:05 -0500
Organization: Michigan State University

In article <[e-mail]>,
[e-mail] (John W. Baxter) writes:
> Sorry, I didn't write that clearly...I meant I don't see a
> significant profit opportunity in disjoint second hands
> wandering correctly through the puzzle part.
>
> I don't think there's much room left for the really small shop
> outside tightly confined niches EXCEPT parts...apps have become to hard
> to write.

Amen. And this is where I place my hope: on things like CodeWarrior with
PowerPlant, QuickDraw GX, OpenDoc, and so on.

All three of these are serious "enabling" technologies that allow a small
developer to compete with the big boys. Want to do any kind of serious
graphics? Before, you had to write your own code. GX hands you a top-notch,
full-featured graphics "engine" for your own use. OpenDoc allows you to avoid
having to add in every feature anyone could possibly want and concentrate on
what you do _well_.

Of course Microsoft _hates_ OpenDoc. (I'm not just saying that; witness OLE
2.0 and Win95 licensing agreements saying you won't develop for OpenDoc.)
Microsoft makes all their money off large, slow, monolithic applications.

                                        / ag





+++++++++++++++++++++++++++

>From "Gerard Allwein" <[e-mail]>
Date: Fri, 20 Jan 1995 07:21:07 -0500
Organization: Computer Science, Indiana University

[e-mail] (Herb Voth) writes:

>Isn't this the problem with OpenDoc, though? I think it is a great
>concept whose time has come, but parts won't make money - applications
>that can use parts will.

>I think it will be a great way for things like TextEdit to be
>'contained' in an application. If you support one, you support them
>all is a creed that will make me happy... if it works out that way.

>-Randall

I think the jury's still out, although my hunch too is that parts
aren't going to make money. I'm looking at OpenDoc purely for helping
us straighten out our internal development. I don't care nor would I
trust parts from somewhere else.

Gerry

+++++++++++++++++++++++++++

>From [e-mail] (Andrew Geweke)
Date: Fri, 20 Jan 1995 13:30:54 -0500
Organization: Michigan State University

In article <[e-mail]>, "Gerard Allwein" <
[e-mail]> writes:
> I think the jury's still out, although my hunch too is that parts
> aren't going to make money. I'm looking at OpenDoc purely for helping
> us straighten out our internal development. I don't care nor would I
> trust parts from somewhere else.

Hmmm. Considering a part isn't all _that_ different from an application -- do
you write your own word processors, spreadsheets, operating systems, and so
on, or do you trust software from other people?

Hell, I trust libraries full of source code from other people, and so do most
people. It's the only way not to kill yourself.

Maybe parts won't make _you_ money -- but if I can develop one by myself or in
a fairly small shop, selling it for $100 should make me _plenty_ of money :-)

                                                / ag





+++++++++++++++++++++++++++

>From [e-mail] ([e-mail])
Date: 20 Jan 1995 15:30:48 GMT
Organization: Dartmouth College, Hanover, NH

In article <[e-mail]>
[e-mail] (Gavin Eadie) writes:
> In article <3fkm4q$[e-mail]>, [e-mail] (John Raley) wrote:
>
> > Was it just me, or did OpenDoc seem unstable as hell?  I'm not talking
> > about having the go-round with the Third-party stuff not running on a
> > 68K mac - I'm talking about the sample parts crashing and hanging for
> > no apparant reason.
> >
> > I'm all for stopping an MS monopoly in this new area, but it's gonna
> > take more than we've got right now.
>
>     Jeez ... People complain they don't have access to early test versions
> of new technology and then they complain when they get it that it doesn't
> behave like final product.  The beta OpenDoc release is for developers who
> want to get their stuff ready for OpenDoc, it's not for people to use.
> Give me a break - take it or leave it but cut the whining.

I think the complaint is valid.  Apple started promoting OpenDoc over a
year and a half ago at the WWDC (it was called "Amber" back then).
Over 2 1/2 years ago at the previous WWDC, ATG was showing off this
"object" technology that was the precursor (in behaviour) to OpenDoc.

Apple has been heavy evangelizing OpenDoc to developers ever since, and
I have seen many demos of OD parts that were stable and responsive.
What a shock it was to get the OpenDoc with SOM CD and see how
primitive the release was!  I had the same experience that John had,
and on my 7100 (20 MB, 256K Cache card) I had to wait _minutes_ to open
simple "draw a square" parts.

The whole time I was thinking "who has a copy of the version that I
have seen demonstrated".  No doubt OpenDoc is quite interesting, and I
think will make the Mac shareware market boom.  Hopefully it will have
the same effect for commercial developers as well.

To be sure, Gavin is also right.  We can't expect beta software to
behave like the final release.  But we can still ask "Is this all we've
got?"

Mark.

- --------------------------------------------------------------------
"On the Internet, nobody knows you're a dog."   Ice Peak Form Mice Elf
                    -- cartoon in New Yorker

+++++++++++++++++++++++++++

>From [e-mail] (Lawson English)
Date: 21 Jan 1995 06:37:23 GMT
Organization: Primenet

Andrew Geweke ([e-mail]) wrote:
[snipt]
: Of course Microsoft _hates_ OpenDoc. (I'm not just saying that; witness OLE
: 2.0 and Win95 licensing agreements saying you won't develop for OpenDoc.)
: Microsoft makes all their money off large, slow, monolithic applications.

:                                       / ag

Is this true? Can MS actually legally require this?



--
- -----------------------------------------------------------------------------
Lawson English                            __  __     ____  ___       ___ ____
[e-mail]                     /__)/__) / / / / /_  /\  / /_    /
                                        /   / \  / / / / /__ /  \/ /___  /
- -----------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Sat, 21 Jan 1995 11:59:36 +0100
Organization: The Conspiracy

In article <3fkm4q$[e-mail]>,
[e-mail] (John Raley) wrote:

>I'm all for stopping an MS monopoly in this new area, but it's gonna
>take more than we've got right now.

It's sad that the users impression of OpenDoc comes from the
sample parts, and not from the technology. I said the same
thing at the Stockholm kitchen in October, but engineering
gives the OpenDoc code priority over the often old and crude
sample parts. I don't wholly disagree with that priority.

Cheers,

                                        / h+


--
  Jon Wdtte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden

  Does Bjarne Stroustrup ever run naked through the woods,
  drumming with the wolves? I think not. -- Jens Alfke


+++++++++++++++++++++++++++

>From "Gerard Allwein" <[e-mail]>
Date: Sat, 21 Jan 1995 08:28:04 -0500
Organization: Computer Science, Indiana University

[e-mail] (Andrew Geweke) writes:

>In article <[e-mail]>, "Gerard Allwein" <
>[e-mail]> writes:
>> I think the jury's still out, although my hunch too is that parts
>> aren't going to make money. I'm looking at OpenDoc purely for helping
>> us straighten out our internal development. I don't care nor would I
>> trust parts from somewhere else.

>Hmmm. Considering a part isn't all _that_ different from an application -- do
>you write your own word processors, spreadsheets, operating systems, and so
>on, or do you trust software from other people?

If applications are too big for the small shop to successfully compete
with, then calling them parts isn't changing anything.

>Hell, I trust libraries full of source code from other people, and so do most
>people. It's the only way not to kill yourself.

I don't use small, special purpose libraries done by one or two
individuals. Maybe I should, but I've never found one that did enough
for me to justify the effort for me to learn and use them.

>Maybe parts won't make _you_ money -- but if I can develop one by myself or in
>a fairly small shop, selling it for $100 should make me _plenty_ of money :-)

>                                               / ag

I hope you do make money on small parts, I would rather see the small
shops more successful. But I simply don't have any reason to believe
that it will happen just yet.

Gerry




+++++++++++++++++++++++++++

>From [e-mail] (Andrew Geweke)
Date: Sat, 21 Jan 1995 14:31:17 -0500
Organization: Michigan State University

In article <3fqa33$[e-mail]>, [e-mail] (Lawson
English) writes:
> Andrew Geweke ([e-mail]) wrote: [snipt]
> : Of course Microsoft _hates_ OpenDoc. (I'm not just saying that;
> witness OLE : 2.0 and Win95 licensing agreements saying you won't
> develop for OpenDoc.) : Microsoft makes all their money off large,
> slow, monolithic applications.
>
> :                                     / ag
>
> Is this true? Can MS actually legally require this?

I know that there was at least an attempt to require this; I'm not sure
whether or not it went through.

Microsoft will stop at nothing to dominate the software industry. Once you
remember that, everything else flows.

                                        / ag





+++++++++++++++++++++++++++

>From [e-mail] (John Nagle)
Date: Sun, 22 Jan 1995 04:18:29 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

[e-mail] (Andrew Geweke) writes:
>In article <3fqa33$[e-mail]>, [e-mail] (Lawson
>English) writes:
>> Andrew Geweke ([e-mail]) wrote: [snipt]
>> : Of course Microsoft _hates_ OpenDoc. (I'm not just saying that;
>> witness OLE : 2.0 and Win95 licensing agreements saying you won't
>> develop for OpenDoc.) : Microsoft makes all their money off large,
>> slow, monolithic applications.
>> Is this true? Can MS actually legally require this?
>I know that there was at least an attempt to require this; I'm not sure
>whether or not it went through.

     At one point, Microsoft was insisting that developers who saw
early versions of OLE under nondisclosure not be in a position to leak
details to Apple, because Apple was designing OpenDoc at the time,
but now that OLE is shipping, the issue is moot.

                                        John Nagle

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Sat, 21 Jan 1995 23:05:51 -0800
Organization: Internet for the Olympic Peninsula

In article <3fqa33$[e-mail]>, [e-mail] (Lawson
English) wrote:

> Andrew Geweke ([e-mail]) wrote:
> [snipt]
> : Of course Microsoft _hates_ OpenDoc. (I'm not just saying that; witness OLE
> : 2.0 and Win95 licensing agreements saying you won't develop for OpenDoc.)
> : Microsoft makes all their money off large, slow, monolithic applications.
>
> :                                       / ag
>
> Is this true? Can MS actually legally require this?

Probably not...but it's a legal question, so nobody knows.  In practice
they can't, unless they want WordPerfect Corp to not support OLE.
WordPerfect is implementing OpenDoc for the Windows platform (sort of
counts as developing for OpenDoc).

   --John

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
       Isn't C fun?
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Howard Berkey)
Date: 22 Jan 1995 06:22:56 GMT
Organization: Premenos Corp.

In article <3fqa33$[e-mail]>,
Lawson English <[e-mail]> wrote:
>Andrew Geweke ([e-mail]) wrote:
>[snipt]
>: Of course Microsoft _hates_ OpenDoc. (I'm not just saying that; witness OLE
>: 2.0 and Win95 licensing agreements saying you won't develop for OpenDoc.)
>: Microsoft makes all their money off large, slow, monolithic applications.
>
>:                                      / ag
>
>Is this true? Can MS actually legally require this?
>

I doubt it is legal if true.  It wouldn't be the wierdest thing I've
heard though... the restrictions on MFC certainly surprised me too.
OpenDoc could be looked at as being in competition with OLE so this
could be construed as M$ trying to create/enforce a monopoly.

Where's the FTC when you need them?  Oh yeah, they were acquired by
Micro$oft.  :-)

-H-


--
Howard Berkey                                     [e-mail]
                   Windows '95 == Macintosh '84

+++++++++++++++++++++++++++

>From [e-mail] (ObjFactory)
Date: 22 Jan 1995 22:47:33 -0500
Organization: America Online, Inc. (1-800-827-6364)

[e-mail] (Lawson English) wrote:

>Andrew Geweke ([e-mail]) wrote:
>[snipt]
>: Of course Microsoft _hates_ OpenDoc. (I'm not just saying that; witness
OLE
>: 2.0 and Win95 licensing agreements saying you won't develop for
OpenDoc.)
>: Microsoft makes all their money off large, slow, monolithic
applications.

>:      / ag

>Is this true? Can MS actually legally require this?

Legally, sure. They could legally require that you stand on one leg and
talk only to your dog. After all, it's their beta program. But the
anti-OpenDoc thing got them a lot of bad PR and some unwanted attention
from the Justice department, so I believe they have dropped it.

Bob Foster
Object Factory
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (ObjFactory)
Date: 22 Jan 1995 23:34:08 -0500
Organization: America Online, Inc. (1-800-827-6364)

[e-mail] (Ed Anson) wrote:

>...Some of the parts work a little, but not enough to be interesting.
Then >my Mac crashes. Perhaps they still need a bit of work.

True. On the other hand, as a part developer I've been impressed with how
solid this version is when it's running my code and how easy development
and debugging has been using both MetroWerks and Rainbow (in beta).

Bob Foster
Object Factory
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Ed Anson)
Date: Mon, 23 Jan 1995 02:01:35 -0500
Organization: Tulip Software

In article <3fvbk0$[e-mail]>, [e-mail]
(ObjFactory) wrote:

> [e-mail] (Ed Anson) wrote:
>
> >...Some of the parts work a little, but not enough to be interesting.
> Then >my Mac crashes. Perhaps they still need a bit of work.
>
> True. On the other hand, as a part developer I've been impressed with how
> solid this version is when it's running my code and how easy development
> and debugging has been using both MetroWerks and Rainbow (in beta).

Bob,

That's encouraging news. What you seem to be saying is that OpenDoc works
reasonably well and the demos are crap. I can accept that.

I have been looking for the right time to start working with OpenDoc. So
far, I haven't had much encouragement. Perhaps when the OPF starts
becoming available, it will be reasonable for me to do something real.

Thanks for the update.

- --------------------
Ed Anson            Macintosh software development services
Tulip Software      MediaTree: multimedia outline editor & catalog
Andover, MA 01810
U.S.A.              For details, check out my WWW page:
                    <http://www.tiac.net/users/tulip/home.html>

+++++++++++++++++++++++++++

>From [e-mail] (ObjFactory)
Date: 22 Jan 1995 23:00:26 -0500
Organization: America Online, Inc. (1-800-827-6364)

"Gerard Allwein" <[e-mail]> wrote:

>...I don't use small, special purpose libraries done by one or two
>individuals...

You may use more of these than you realize, but that's not the point. The
most active OpenDoc developer I'm aware of is Claris - or maybe it's
Novell. It sure isn't Joe's Garage. In general, larger companies are more
likely to invest in new technology than small companies and individuals,
for the simple reason that larger companies are more able to afford
writing off years of development if the new thing doesn't pan out. I think
it is safe to say that if or when OpenDoc parts become an industry, most
of the players will be companies you already do business with. Because
OpenDoc is intrinsically more extensible than current application
technology, there will be more opportunities for smaller players, too. The
latter can overcome your sales resistance by making products you are
already willing to buy more useful without extracting a huge penalty in
learning and instability.

Bob Foster
Object Factory
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Herb Voth)
Date: 24 Jan 95 11:35:34 GMT
Organization: Simon Fraser University

>>Maybe parts won't make _you_ money -- but if I can develop one by myself or in
>>a fairly small shop, selling it for $100 should make me _plenty_ of money :-)

>I hope you do make money on small parts, I would rather see the small
>shops more successful. But I simply don't have any reason to believe
>that it will happen just yet.

A little dreaming never hurt anyone.

The only successful thing that resembles OpenDoc that I can think of is
Photoshop and XPress plugins. I doubt Apple is going to push OpenDoc parts
like Quark has done with their plugins. I think however that plugins have
been part of the reason for Quark's amazing success in the professional
publishing industry.

I suppose WordPerfect/Novell may be able to pull something like this - as
long as they don't see small publishers as a threat to their own
business. Seeing as Microsoft will probably lag in support for OpenDoc,
WordPerfect may pull a similar stunt that Quark did while Aldus was
asleep at the switch.

But, it is always easier to succeed in a small, focused field than in
such a field as word processing.

And there is always the threat such as, if you *are* successful,
WordPerfect or Apple will crank out an extension to either the System or
WordPerfect, and instantly you have no revenue. Small shop becomes closed
shop overnight.

Well, you can always count on sheep - and dream :-)

-Randall


+++++++++++++++++++++++++++

>From [e-mail] (ObjFactory)
Date: 24 Jan 1995 15:15:18 -0500
Organization: America Online, Inc. (1-800-827-6364)

[e-mail] (Herb Voth) wrote:

>The only successful thing that resembles OpenDoc that I can think of is
>Photoshop and XPress plugins. I doubt Apple is going to push OpenDoc
parts
>like Quark has done with their plugins. I think however that plugins have
>been part of the reason for Quark's amazing success in the professional
>publishing industry.

I would certainly hope that Apple has the sense to do this. For example,
Apple's StarCore seems to be the reason there is still any horizontal
Newton software market at all. If Apple wants part development to survive
as a cottage industry, it is going to have to make sure the cottages have
distribution channels.

>[snip]
>And there is always the threat such as, if you *are* successful,
>WordPerfect or Apple will crank out an extension to either the System or
>WordPerfect, and instantly you have no revenue. Small shop becomes closed

>shop overnight.

Isn't this part of the dictionary definition of small shop? :) But more
and more small developer output is being purchased, rather than
reinvented, by larger vendors. Unless time-to-market stops being a primary
consideration, I think this is a trend.

Bob Foster
Object Factory
[e-mail]

+++++++++++++++++++++++++++

>From "Gerard Allwein" <[e-mail]>
Date: Wed, 25 Jan 1995 07:46:24 -0500
Organization: Computer Science, Indiana University

[e-mail] (ObjFactory) writes:

>Isn't this part of the dictionary definition of small shop? :) But more
>and more small developer output is being purchased, rather than
>reinvented, by larger vendors. Unless time-to-market stops being a primary
>consideration, I think this is a trend.

>Bob Foster
>Object Factory
>[e-mail]

Do have any examples to support your view that this is trend? Does
anyone else? If small parts are a market to emerge, we should be able
to see some trace of it now...something along the lines of "this
company's stuff will translate easily into small parts and their
market will still be there."

Gerry

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Thu, 26 Jan 1995 11:11:18 +0100
Organization: The Conspiracy

In article <[e-mail]>,
[e-mail] (Herb Voth) wrote:

>The only successful thing that resembles OpenDoc that I can think of is
>Photoshop and XPress plugins. I doubt Apple is going to push OpenDoc parts
>like Quark has done with their plugins. I think however that plugins have
>been part of the reason for Quark's amazing success in the professional
>publishing industry.

Well, it certainly isn't the crashing :-) (Seriously, 3.31
isn't too shabby in that regard)

Apple is not going to push OpenDoc and its parts as Quark does
XTensions.

The Apple effort is going to make Quark marketing look like a
plastic toy you get for a quarter with your bubblegum. At least
if you believe the Apple evangelism hype about OpenDoc -
according to that, the entire company rests on OpenDoc, and
it's success or bust.

>I suppose WordPerfect/Novell may be able to pull something like this - as
>long as they don't see small publishers as a threat to their own

Quote Word Perfect: "We would like WordPerfect to be everyone's
container of choise."

>But, it is always easier to succeed in a small, focused field than in
>such a field as word processing.

Tell that to the guy who made his movie script writing
application standard in Hollywood, to the point that you HAVE
to write scripts with it. William Gibson thought the program
sucked, but he had to use it, according to an interview. I
haven't seen it, but I think the business idea is brilliant.

Cheers,

                                                / h+


--
  Jon Wdtte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden
  Which would you rather: That your son said "I've killed a man" or that
  your daughter said "I'm pregnant" ?

  Now, which is most dangerous on TV: sex or violence?


+++++++++++++++++++++++++++

>From [e-mail] (John Nagle)
Date: Thu, 26 Jan 1995 17:17:14 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

"Gerard Allwein" <[e-mail]> writes:
>Do have any examples to support your view that this is trend? Does
>anyone else? If small parts are a market to emerge, we should be able
>to see some trace of it now...something along the lines of "this
>company's stuff will translate easily into small parts and their
>market will still be there."

     Markets in Visual Basic buttons and Microsoft Windows DLLs exist.
That seems to indicate the direction the market is taking.

                                        John Nagle

+++++++++++++++++++++++++++

>From [e-mail] (Herb Voth)
Date: 27 Jan 95 10:54:31 GMT
Organization: Simon Fraser University

[e-mail] (John Nagle) writes:

>"Gerard Allwein" <[e-mail]> writes:
>>Do have any examples to support your view that this is trend? Does
>>anyone else? If small parts are a market to emerge, we should be able
>>to see some trace of it now...something along the lines of "this
>>company's stuff will translate easily into small parts and their
>>market will still be there."

>     Markets in Visual Basic buttons and Microsoft Windows DLLs exist.
>That seems to indicate the direction the market is taking.

Confuse me if I'm wrong here, but buttons and DLLs are not anything
remotely similar to selling parts.

What we should be looking at is extensions to applications such as Lotus
Notes, Quark Xpress and Photoshop. Some people are making a healthy
living at this.

DLLs may sell to programmers, but try and sell one to your average Word user.

I think that OpenDoc is primarily going to appeal to people who like to
customize their working environment. People who currently are customers
for Macro programs. People who routinely work with diverse documents and
do a lot of exporting/importing.

But lets face it, you're not going to see Photoshop or XPress parts. That
has been tried with OLE and it is ungainly. These applications will most
likely be containers.

Boy, it would be nice to load up PageMaker and have a Finale document
appear, completely editable, on the page. Will this ever happen? I doubt
it. But, if Finale ever supports OpenDoc, the programmers can spend their
time writing music and leave the other things to parts: Text, line
drawing... such things will be included with the System or with major
applications... and these things are what people will use.
My prediction: OpenDoc will become the primary way for Apple to add
functionality to the System and the same for major application
developers. Shareware parts will be prevalent but will crash the System
50 times per working day. A few guys will make a killing with special,
vertical type parts through direct sales to those needing them.

and... drum roll please... the outliner will make a big time comeback as
the document processor of choice... It is the perfect OpenDoc container.

So sleep tight. Apps are here to stay.

-Randall


+++++++++++++++++++++++++++

>From [e-mail] (Caleb Strockbine)
Date: 27 Jan 1995 18:27:49 GMT
Organization: SUNY Stony Brook

In article <[e-mail]> "Gerard Allwein" <[e-mail]> writes:
>Do have any examples to support your view that this is trend? Does
>anyone else? If small parts are a market to emerge, we should be able
>to see some trace of it now...something along the lines of "this
>company's stuff will translate easily into small parts and their
>market will still be there."


I think it's not so much a matter of "WordPerfect will suddenly be replaced by
a set of n small parts" as "if WordPerfect supports OpenDoc, there will
suddenly be great opportunities for small third parties to add value to
an established product." There are plenty of examples of small companies
which have been very successful creating extensions for existing apps which
support some kind of extension. HyperCard, PhotoShop, XPress, Excel,
4th Dimension, Visual Basic (for the PC, of course), and many others
are supported by miniature industries which add value by creating extensions.
These are all products which have been great for small developers. And in
many cases, small developers create these extensions for specialty markets
(or even single clients) which aren't attractive to large developers.

On the flip side of things, there's plenty of incentive for large companies
which make large apps to add support for OpenDoc. By making relatively
small modifications, an existing app can support parts and become instantly
extensible. And as an app evolves, those same companies can start to add
features to their own product by writing their own parts. They might even
re-implement some existing features as parts and actually REDUCE the size
of their app.

I think it's more than a trend... I'd say it's an established segment of
the industry that's about to experience huge growth.

Caleb Strockbine
[e-mail]



--

........................................................................
"As recently as 1984, the NSA measured its total computer capacity
 not in MIPS, not in MFLOPS, but in *acres*." - _PGP_ by Simson Garfinkel

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: 27 Jan 1995 19:13:17 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <[e-mail]>, [e-mail] (Herb Voth) wrote:

< [e-mail] (John Nagle) writes:
<
<
< What we should be looking at is extensions to applications such as Lotus
< Notes, Quark Xpress and Photoshop. Some people are making a healthy
< living at this.
<
< DLLs may sell to programmers, but try and sell one to your average Word user.
<
< I think that OpenDoc is primarily going to appeal to people who like to
< customize their working environment. People who currently are customers
< for Macro programs. People who routinely work with diverse documents and
< do a lot of exporting/importing.
<
< So sleep tight. Apps are here to stay.
<
< -Randall

I have a friend who writes training manuals for a living.  He uses
PageMaker to generate his documents and a variety of other apps to
generate text and graphics.  Many of his manuals contain tables.
Pagemaker's table editor sucks.  He likes to use the Word table editing
capability.  But guess what?  PageMaker can't import Word tables.  What he
does is generate his tables in Word and use PrintToPict to generate a Pict
version of each table.  These can then be imported into PageMaker.  Think
about editing 10 or 20 tables this way.  UGGH!!

Now imagine a table part.  It's not written by PageMaker but it is
supported by PageMaker.  Anyone can now edit a table in any part container
and import it into any other part container with no problems.  I think
people would pay money for a good table editor part.

--
Brian  Stern  :-{)}
Toolbox commando and Menu bard
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Herb Voth)
Date: 28 Jan 95 11:46:24 GMT
Organization: Simon Fraser University

[e-mail] (Brian Stern) writes:

>I have a friend who writes training manuals for a living.  He uses
>PageMaker to generate his documents and a variety of other apps to
>generate text and graphics.  Many of his manuals contain tables.
>Pagemaker's table editor sucks.  He likes to use the Word table editing
>capability.  But guess what?  PageMaker can't import Word tables.  What he
>does is generate his tables in Word and use PrintToPict to generate a Pict
>version of each table.  These can then be imported into PageMaker.  Think
>about editing 10 or 20 tables this way.  UGGH!!

Reminds me of when we first started publishing music. Finale to the rescue.

>Now imagine a table part.  It's not written by PageMaker but it is
>supported by PageMaker.  Anyone can now edit a table in any part container
>and import it into any other part container with no problems.  I think
>people would pay money for a good table editor part.

Precisely how OpenDoc will be applied. But, guess what. Word will have a
Table part. WordPerfect will have a Table part. You won't run out and buy
one because it will already be buried somewhere on one of the 50 CD
install disks these programs will ship with.

I agree, it's gonna be great. What remains to be seen is whether people
will actually make money developing *parts*.

I put my money on container applications. If feature lists sell programs,
then he with the most parts, wins.

Reminds me of getting Lego blocks for Christmas. Ah the sweet memories of
youth...

-Randall

+++++++++++++++++++++++++++

>From [e-mail] (Matthew Melmon)
Date: Tue, 24 Jan 1995 21:28:03 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (John Nagle) wrote:


>      At one point, Microsoft was insisting that developers who saw
> early versions of OLE under nondisclosure not be in a position to leak
> details to Apple, because Apple was designing OpenDoc at the time,
> but now that OLE is shipping, the issue is moot.

Now *that* is a *truly* *brilliant* example of fudging the
truth.  In fact, Microsoft required - in WordPerfect's contract -
that the same engineers working on OLE functionality be prohibited
from working on "any other component technology."  The careful
observer will note that this would require two completely
different engineering teams working on essentially the
same functionality.  The careful observer will also note that
maintaining two completely separate engineering teams is beyond
the resources of many software companies, and probably impossible,
given the nature of software development.  Here's George, and
George will _only_ add OLE functionality to WordPerfect.  Here's
Sam, and Sam will _only_ add OpenDoc functionality to WordPerfect.

Yeah.  Right.

WordPerfect objected, the story was plastered across every
industry rag from MacWeek to ComputerWorld, and Microsoft
both furiously explained how it was not involved in predatory
anti-competitive practices _and_ dropped the requirement.

Making the point, as you say, moot.  But a little before,
as you say, OLE shipped.

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Sun, 29 Jan 1995 18:27:13 +0100
Organization: The Conspiracy

In article <[e-mail]>,
[e-mail] (Herb Voth) wrote:

>I think that OpenDoc is primarily going to appeal to people who like to
>customize their working environment. People who currently are customers
>for Macro programs. People who routinely work with diverse documents and
>do a lot of exporting/importing.

I think we'll see the term "programmer" become split in two:

One kind who gets down dirty and writes the actual parts in C++
or Dylan or whatever. This is what we know as "programmer" today.

One kind who USES parts, puts stationery together of different
parts, and glues them together with AppleScript (nee OpenScript)
This is what we know as an "indispensible power user" in most
corporate settings today. Or maybe some of the 4D people will
find attractive business propositions here.

The thing is: the stationery is what you deliver. Your default
stationery is just one document with your part in it. It can be
dropped in another document to embed the part, or it can be
double-clicked to just work with a blank copy of your part.

However, dropping several parts of stationery in one document,
tying them together with some Paste Links and/or scripting, and
saving as new stationery, looks like creating a WHOLE NEW
APPLICATION to the user, even though you're just re-using
the same OpenDoc parts written in C++. In that sense, OpenDoc
revolutionizes application development as being the penultimate
interface design application.

Cheers,

                                                        / h+


--
  Jon Wdtte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden

  CFM 68k - Solutions to yesterdays problems, tomorrow!


+++++++++++++++++++++++++++

>From [e-mail] (ObjFactory)
Date: 30 Jan 1995 04:35:57 -0500
Organization: America Online, Inc. (1-800-827-6364)

"Gerard Allwein" <[e-mail]> wrote:

>[e-mail] (ObjFactory) writes:

>>Isn't this part of the dictionary definition of small shop? :) But more
>>and more small developer output is being purchased, rather than
>>reinvented, by larger vendors. Unless time-to-market stops being a
primary
>>consideration, I think this is a trend.

>Do have any examples to support your view that this is trend? Does
>anyone else? If small parts are a market to emerge, we should be able
>to see some trace of it now...something along the lines of "this
>company's stuff will translate easily into small parts and their
>market will still be there."

Examples? How about the throngs involved in making Word, Excel, Quark,
PhotoShop, PageMaker, etc. extensions, macros and "art"? Did you notice
where most of the user interface content in System 7.5 came from? By and
large these small components are produced by small companies, and have
found their way into the mainstream. Just look at OpenDoc as enabling
technology for an already burgeoning components industry.

Bob Foster
Object Factory
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Kent Sandvik)
Date: Sat, 28 Jan 1995 12:51:41 -0800
Organization: Apple Computer, Inc. Developer Technical Support

In article <[e-mail]>, [e-mail] (Herb Voth) wrote:
> And there is always the threat such as, if you *are* successful,
> WordPerfect or Apple will crank out an extension to either the System or
> WordPerfect, and instantly you have no revenue. Small shop becomes closed
> shop overnight.

I would not worry about this too much, the field of application
development is very big, and large companies, even with their resources,
just can't do everything. Actually, OpenDoc is a good start for new
companies as this is new technology, and the next generation of larger SW
companies usually start with the introduction of a new paradigm of
computing... I would personally take a very close look at components/parts
that operate over the network, for instance.

--Kent

--
Kent Sandvik   [e-mail]   New Media Analyst/Programmer
Private activities on Internet.

+++++++++++++++++++++++++++

>From [e-mail] (Ed Anson)
Date: Mon, 30 Jan 1995 17:14:11 -0500
Organization: Tulip Software

In article <sandvik-2801951251410001@17.255.38.138>, [e-mail]
(Kent Sandvik) wrote:

> In article <[e-mail]>, [e-mail] (Herb Voth) wrote:
> > And there is always the threat such as, if you *are* successful,
> > WordPerfect or Apple will crank out an extension to either the System or
> > WordPerfect, and instantly you have no revenue. Small shop becomes closed
> > shop overnight.
>
> I would not worry about this too much, the field of application
> development is very big, and large companies, even with their resources,
> just can't do everything. Actually, OpenDoc is a good start for new
> companies as this is new technology, and the next generation of larger SW
> companies usually start with the introduction of a new paradigm of
> computing... I would personally take a very close look at components/parts
> that operate over the network, for instance.

Actually I would worry about this. It has happened, and will happen again.

Naturally, the big companies can't do everything. So they look at what
sells. The little guys get to experiment, innovate and develop the cool
solution to a problem. When it demonstrates an ample market, the big guys
jump in and grab it.

This has happened to me, and I've seen it happen to others. The only way
to protect from this is to be sure the solution only has a small market.
Or be prepared to introduce new products frequently.

- --------------------
Ed Anson            Macintosh software development services
Tulip Software      MediaTree: multimedia outline editor & catalog
Andover, MA 01810
U.S.A.              For details, check out my WWW page:
                    <http://www.tiac.net/users/tulip/home.html>

+++++++++++++++++++++++++++

>From [e-mail] (Jerome Chan)
Date: Tue, 31 Jan 1995 21:40:53 -0500
Organization: TofuSoft

How does OpenDoc deal with AppleScript?

- -
 The Evil Tofu (Why be human?)

+++++++++++++++++++++++++++

>From [e-mail] (Avi Rappoport)
Date: 1 Feb 1995 18:04:15 GMT
Organization: metrowerks, Inc.

In article <[e-mail]>, [e-mail] (Herb Voth) wrote:

snipped
)
) DLLs may sell to programmers, but try and sell one to your average Word user.

My old company sold a bibliographic database "part" (EndNote Plug-In
Module) to Word users.  It was a wild success.

) I think that OpenDoc is primarily going to appeal to people who like to
) customize their working environment. People who currently are customers
) for Macro programs. People who routinely work with diverse documents and
) do a lot of exporting/importing.

People who need features that are not supported by the standard tools.

) But lets face it, you're not going to see Photoshop or XPress parts. That
) has been tried with OLE and it is ungainly. These applications will most
) likely be containers.

Photoshop seems like a fairly good part (remember that parts can include
other parts).  One often wants to *do something* with a picture, not just
edit it.  Whereas XPRess would probably be an application.

) Boy, it would be nice to load up PageMaker and have a Finale document
) appear, completely editable, on the page. Will this ever happen? I doubt
) it. But, if Finale ever supports OpenDoc, the programmers can spend their
) time writing music and leave the other things to parts: Text, line
) drawing... such things will be included with the System or with major
) applications... and these things are what people will use.

Exactly.

) My prediction: OpenDoc will become the primary way for Apple to add
) functionality to the System and the same for major application
) developers. Shareware parts will be prevalent but will crash the System
) 50 times per working day. A few guys will make a killing with special,
) vertical type parts through direct sales to those needing them.
)
) and... drum roll please... the outliner will make a big time comeback as
) the document processor of choice... It is the perfect OpenDoc container.
)
) So sleep tight. Apps are here to stay.

Your vision contradicts your last sentance.  I don't know what's going to
happen, but I'm looking forward to a Really Good Outliner (remember
MindWrite?)

--
Avi Rappoport
metrowerks User Advocate & Documentation Lead
[e-mail]
[currently victim of a glacial newsfeed]

+++++++++++++++++++++++++++

>From Tim Moore <[e-mail]>
Date: Thu, 02 Feb 95 20:41:54 -0500
Organization: Tembel's Hedonic Commune


In article <[e-mail]>, Ed Anson writes:

>
> In article <sandvik-2801951251410001@17.255.38.138>,
[e-mail]
> (Kent Sandvik) wrote:
>
> > In article <[e-mail]>, [e-mail] (Herb
Voth) wrote:
> > > And there is always the threat such as, if you *are* successful,

> > > WordPerfect or Apple will crank out an extension to either the
System or
> > > WordPerfect, and instantly you have no revenue. Small shop
becomes
> > > closed
> > > shop overnight.
> >
> > I would not worry about this too much, the field of application
> > development is very big, and large companies, even with their
resources,
> > just can't do everything. Actually, OpenDoc is a good start for
new
> > companies as this is new technology, and the next generation of
larger SW
> > companies usually start with the introduction of a new paradigm
of
> > computing... I would personally take a very close look at
components/parts
> > that operate over the network, for instance.
>
> Actually I would worry about this. It has happened, and will happen
again.
>
> Naturally, the big companies can't do everything. So they look at
what
> sells. The little guys get to experiment, innovate and develop the
cool
> solution to a problem. When it demonstrates an ample market, the big
guys
> jump in and grab it.
>
> This has happened to me, and I've seen it happen to others. The only
way
> to protect from this is to be sure the solution only has a small
market.
> Or be prepared to introduce new products frequently.

Or you could become big :-)  I know that it's easier said than done,
but if you have a good, innovative product then amazing things can
happen--look at Metrowerks.  They wrote a product that did new things,
and did old things better (at least in my opinion) than other
products.  A company that, in 1992 was almost completely unknown, is
in 1995 taking over the programming market.

Of course, this is the exception...but everyone can have wishful
thinking :-)

>
> ----------------------
> Ed Anson            Macintosh software development services
> Tulip Software      MediaTree: multimedia outline editor & catalog
> Andover, MA 01810
> U.S.A.              For details, check out my WWW page:
>                     <http://www.tiac.net/users/tulip/home.html>

--

Tim Moore
Tembel's Hedonic Commune


+++++++++++++++++++++++++++

>From [e-mail] (Jens Alfke)
Date: Fri, 3 Feb 1995 21:54:47 GMT
Organization: Apple Computer, Inc.

> In article <[e-mail]>, [e-mail] (Herb Voth) wrote:
> ) But lets face it, you're not going to see Photoshop or XPress parts. That
> ) has been tried with OLE and it is ungainly. These applications will most
> ) likely be containers.

It was ungainly in OLE because OLE is an ungainly architecture; the best
description is from Jon Watte of Metrowerks, who described it as "two
mega-apps drawing into each others' windows". Which is basically correct.
OpenDoc takes a much more lightweight approach; it's difficult to see any
visible seams between a container and its embedded parts.

> ) My prediction: OpenDoc will become the primary way for Apple to add
> ) functionality to the System and the same for major application
> ) developers. Shareware parts will be prevalent but will crash the System
> ) 50 times per working day.

There is a certification process that runs parts through tests to make
sure they behave correctly. CILabs will be administering these tests, and
editors that pass will get a special sticker. There will be a smaller
series of tests that smaller developers and shareware authors can run on
their own to get a less rigorous certification, one which is of course
based on the honor system since CILabs isn't directly involved. This
should help somewhat. Of course, commercial software will still be, in
general, more stable; but that's how it's always been...


Jens Alfke_________OpenDoc [e-mail]
                                           OpenDoc info: FTP to CILabs.org

         Visit Scenic Flood Control Dam No. 3.

+++++++++++++++++++++++++++

>From [e-mail] (Jens Alfke)
Date: Fri, 3 Feb 1995 21:33:13 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Herb Voth) wrote:

> The only successful thing that resembles OpenDoc that I can think of is
> Photoshop and XPress plugins. I doubt Apple is going to push OpenDoc parts
> like Quark has done with their plugins. I think however that plugins have
> been part of the reason for Quark's amazing success in the professional
> publishing industry.

A similar case is the thriving market for VBX's, plug-in controls for
Visual Basic. There are many companies and magazines focusing on just this
market.

It's not quite the same scenario; OpenDoc parts aren't plug-ins for any
particular type of application, they're generic and universal. They can be
the root of a document as well as something you can drop into any other
kind of document.


> And there is always the threat such as, if you *are* successful,
> WordPerfect or Apple will crank out an extension to either the System or
> WordPerfect, and instantly you have no revenue. Small shop becomes closed
> shop overnight.

Part of the appeal of OpenDoc for traditional app developers is that they
no longer compelled to provide every single feature that users might want,
even if it's not central to what their app does. Why does a word processor
need a draw package built in? Chances are someone else has a better draw
package already. By supporting OpenDoc, you open your app to any type of
plug-in and save the development effort of adding a constant stream of new
doodads.

In many ways it's an opportunity for small vendors. If you don't like the
chart module that comes with the OpenDoc-compatible ClarisWorks, you can
buy _my_ much better chart module and just plug it in transparently.
There's much less barrier to the user's doing so, because the plug-in
works so smoothly with its surroundings; unlike today where using a
separate charting package is fraught with peril as you have to navigate
Publish & Subscribe or the Clipboard.


Jens Alfke_________OpenDoc [e-mail]
                                           OpenDoc info: FTP to CILabs.org

         Visit Scenic Flood Control Dam No. 3.

+++++++++++++++++++++++++++

>From [e-mail] (Jens Alfke)
Date: Fri, 3 Feb 1995 21:35:07 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail]
(Jerome Chan) wrote:

> How does OpenDoc deal with AppleScript?

OpenDoc fully supports the OSA (Open Scripting Architecture) which
AppleScript plugs into. Parts can be fully scriptable and can send and
receive Apple events. It makes AS even more compelling when you can use it
to plug parts of the same document together; you can build documents that
behave like custom apps without doing any serious (C/C++/Pascal)
programming.


Jens Alfke_________OpenDoc [e-mail]
                                           OpenDoc info: FTP to CILabs.org

         Visit Scenic Flood Control Dam No. 3.

+++++++++++++++++++++++++++

>From [e-mail] (Jon Pugh)
Date: Sat, 11 Feb 1995 09:09:40 GMT
Organization: Not Organized

In article <[e-mail]>,
[e-mail] (Quinn "The Eskimo!") wrote:

> In article <[e-mail]>, [e-mail]
> (Jerome Chan) wrote:
>
> >How does OpenDoc deal with AppleScript?
>
> No one, including the OpenDoc developer team, knows (:  I was very
> disappointed to see that that the scripting APIs on the MacTech OpenDoc CD
> were still not final ):

Now now.  I've been hired onto the OpenDoc scripting team and I can say
that OpenDoc does scripting.  Some of it has been finalized fairly
recently and there's still a lot of work to do, but the framework is in
place and I'm ready to do my part to make OpenDoc exceedingly scriptable.
I hope you'll trust me to make sure that OpenDoc deals well with
AppleScript.

Time, time, all we need is more time!  ;)

Jon

What are YOU doing to oppose the Microsoft juggernaut?
ftp://ftp.netcom.com/pub/jo/jonpugh/homepage.html

+++++++++++++++++++++++++++

>From [e-mail] (Peter N Lewis)
Date: Sun, 12 Feb 1995 13:39:11 +0800
Organization: Curtin University

In article <[e-mail]>, [e-mail] wrote:

>> Or be prepared to introduce new products frequently.

And what's wrong with that?  It's a good way to keep things interesting
and to avoid the maintenance problem ;-).  I know I was quite happy to
have DeHQX killed off by StuffIt Expander - one less program to maintain
(of course, it was free - it may be more interesting when/if someone
targets one of my more profitable programs :-).

>Or you could become big :-)

Yep, two solutions.  Stay small and lean and quick and just keep doing new
things, or grow big and stay at the front with a few large products.

>happen--look at Metrowerks.  They wrote a product that did new things,
>and did old things better (at least in my opinion) than other
>products.  A company that, in 1992 was almost completely unknown, is
>in 1995 taking over the programming market.

True, but a lot of that was do to a large capital injection (someone
suggested recently that they weren't sure than MW was going to be able to
pay all of that money back - does anyone know where they stand
financially?).  Personally, I think they are in good shape, there are
interesting things happening with Symantec and Language Systems, but to me
it looks like Metrowerks have the most commitment and resources and
drive...

Enjoy,
   Peter.
--
And lo, NewsWatcher did say
  "comp.sys.mac.programmer: Group deleted on news server."
Let February 7 hence forth be know as a day of morning.

+++++++++++++++++++++++++++

>From [e-mail] (Ed Anson)
Date: Mon, 13 Feb 1995 13:46:58 -0500
Organization: Tulip Software

In article <[e-mail]>,
[e-mail] (Peter N Lewis) wrote:

> In article <[e-mail]>, [e-mail] wrote:
>
> >> Or be prepared to introduce new products frequently.
>
> And what's wrong with that?  It's a good way to keep things interesting
> and to avoid the maintenance problem ;-).  I know I was quite happy to
> have DeHQX killed off by StuffIt Expander - one less program to maintain
> (of course, it was free - it may be more interesting when/if someone
> targets one of my more profitable programs :-).

If you're trying to make a living at selling software, such events are a
little too interesting.

It takes quite a bit of time, and a lot of investment, to bring out a new
product. Not only development, but marketing as well. The problem is that,
once the small guy has done the original thinking, shown how to solve the
problem, and developed the market -- the big guys jump in with a cheap
knock-off and reap the profit. This leaves the little guy struggling to
survive.

- --------------------
Ed Anson            Macintosh software development services
Tulip Software      MediaTree: multimedia outline editor & catalog
Andover, MA 01810
U.S.A.              For details, check out my WWW page:
                    <http://www.tiac.net/users/tulip/home.html>

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Wed, 15 Feb 1995 00:55:40 +0100
Organization: The Conspiracy


In article <[e-mail]>,
[e-mail] (Peter N Lewis) wrote:

> True, but a lot of that was do to a large capital injection (someone
> suggested recently that they weren't sure than MW was going to be able to
> pay all of that money back - does anyone know where they stand
> financially?

According to the public reports made to shareholders, they're
ahead of the plan in profitability. I don't have any insight
into the day-to-day economic issues, but they pay in a timely
manner :-)

Cheers,

                                        / h+


--
  Jon Wdtte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden

"Smart Friends ask no SCSI questions!"
     Apple employee at the Bash


+++++++++++++++++++++++++++

>From [e-mail] (Jon Pugh)
Date: Wed, 15 Feb 1995 06:44:54 GMT
Organization: Office in a Box

In article <[e-mail]>,
[e-mail] (Peter N Lewis) wrote:

> Let February 7 hence forth be know as a day of morning.

I hate to be picky, but it's mourning.  ;)

Jon

+++++++++++++++++++++++++++

>From [e-mail] (Kolbjxrn Aambx)
Date: Wed, 15 Feb 1995 08:44:42 +0100
Organization: University of Oslo Library

In article <jonpugh-1102950109400001@192.0.1.2>, [e-mail] (Jon
Pugh) wrote:

> Now now.  I've been hired onto the OpenDoc scripting team and I can say
> that OpenDoc does scripting.  Some of it has been finalized fairly
> recently and there's still a lot of work to do, but the framework is in
> place and I'm ready to do my part to make OpenDoc exceedingly scriptable.
> I hope you'll trust me to make sure that OpenDoc deals well with
> AppleScript.
>

So, will we be able to use OpenDoc as a better replacement for HyperCard
anytime soon?

+++++++++++++++++++++++++++

>From [e-mail] (Robert A. Uhl)
Date: 13 Feb 1995 17:31:08 GMT
Organization: University of Denver

In article <[e-mail]>,
Jens Alfke <[e-mail]> wrote:
>In article <[e-mail]>, [e-mail] (Herb Voth) wrote:
>
>> The only successful thing that resembles OpenDoc that I can think of is
>> Photoshop and XPress plugins. I doubt Apple is going to push OpenDoc parts
>> like Quark has done with their plugins. I think however that plugins have
>> been part of the reason for Quark's amazing success in the professional
>> publishing industry.
>

[snip]

>particular type of application, they're generic and universal. They can be
>the root of a document as well as something you can drop into any other
>kind of document.
>

  The original poster has a point in that Apple might not push OpenDoc
like it should. Look at what happened, or rather failed to happen, with
Publish & Subscribe: an excellent idea is abandoned by all. I always saw
P&S as a sort of advanced clipboard, and used it with several of my
reports. But it wasn't pushed like it should have been, IMHO.

[snip]

>works so smoothly with its surroundings; unlike today where using a
>separate charting package is fraught with peril as you have to navigate
>Publish & Subscribe or the Clipboard.

  'fraught with peril...navigate...Clipboard'! It says somehing when one
of the most powerful features and selling points of the Macintosh is now
put down as difficult. Remember when the very idea of applications using
each other's data was revolutionary? BTW, is it just me, or do apps not
use the Clipboard to the best of their capability?

--
- ------------------------------------------------------------------------
| Bob Uhl | Spectre                  | `En touto nika' +                 |
| U of D  | Baron Robert von Raetzin | http://mercury.cair.du.edu/~ruhl/ |
- ------------------------------------------------------------------------

---------------------------

>From [e-mail] (Patrick Stadelmann)
Subject: PICT file to-from GWorld
Date: Tue, 07 Feb 1995 16:46:21 +0100
Organization: University of Neuchatel

Hi !

I'm writing an app to display custom image file. Basically, the file contains
raw data with a custom header. I've already got the display part working
(I read the data from the file to the pixmap of the GWorld. Now, I'd like
to be able to save the image as a PICT file. I'd also like to know how to
read a PICT file
in a GWorld to display it.

Thanks for your help

Patrick

--
Patrick Stadelmann <[e-mail]>

+++++++++++++++++++++++++++

>From [e-mail] (Chris Rudolph)
Date: Wed, 08 Feb 1995 06:24:34 -0800
Organization: Motion Works International

In article <[e-mail]>,
[e-mail] (Patrick Stadelmann) wrote:

> Hi !
>
> I'm writing an app to display custom image file. Basically, the file contains
> raw data with a custom header. I've already got the display part working
> (I read the data from the file to the pixmap of the GWorld. Now, I'd like
> to be able to save the image as a PICT file. I'd also like to know how to
> read a PICT file
> in a GWorld to display it.
>
> Thanks for your help
>
> Patrick
>
> --
> Patrick Stadelmann <[e-mail]>

Hi Patrick:

Here is a snippet that will work for you.

SetGWorld( yourGWorld, yourDevice );

PicHandle       thePicture = OpenPicture( &yourWorld->portRect );
PixMapHandle    thePixMap = GetGWorldPixMap( yourGWorld );

HLock( (Handle)thePixMap );
if( LockPixels( thePixMap ) )
{
    CopyBits( (BitMap*)*thePixMap,
              (BitMap*)*thePixMap,
              &yourWorld->portRect,
              &yourWorld->portRect,
              srcCopy, 0 );

    ClosePicture();
    UnlockPixel( thePixMap );
}
HUnlock( (Handle)thePixMap );

// thePicture now points to a valid picture.
// NOTE: I'm not doing much error checking.
//

StandardFileReply   theReply;

StandardPutFile( "\pSave PICT file as:", "\puntitled", &theReply);
if( theReply.sfGood )
{
    OSErr   theErr = noErr;

    if( !theReply.sfReplacing )
        theErr = FSpCreate( &theReply.sfFile, 'ttxt', 'PICT', smSystemScript );

    if( theErr == noErr )
    {
        Ptr         header = NewPtrClear( 512 );
        short       refNum;
        long        theSize;

        HLock( (Handle)thePicture );
        theErr = FSpOpenDF( &theReply.sfFile, fsCurPerm, &refNum );
        theErr = SetFPos( refNum, fsFromStart, 0 );
        theErr = FSWrite( refNum, 512, header );
        theErr = FSWrite( refNum, theSize, (Ptr)*thePicture );
        theErr = FSClose( refNum );
        HUnlock( (Handle)thePicture );

        DisposePtr( header );
    }
}

DisposeHandle( (Handle)thePicture );

//

StandardFileReply   theReply;
OSType              theType = 'PICT';

StandardGetFile( 0, 1, &theType, &theReply);
if( !theReply.sfGood )
    return;

PicHandle   thePicture = 0;
long        theSize = 0;
OSErr       theErr = noErr;
short       refNum;

theErr = FSpOpenDF( &theReply.sfFile, fsCurPerm, &refNum );
theErr = SetFPos( refNum, fsFromStart, 512 );   // Skip over header
theErr = GetEOF(refNum, &theSize);

theSize -= 512;

thePicture = (PicHandle)NewHandle( 512 );
if( thePicture )
{
    HLock( (Handle)thePicture );
    theErr = FSRead( refNum, theSize, (Ptr)*thePicture );
    HUnlock( (Handle)thePicture );
}

theErr = FSClose( refNum );


That should do it.  It isn't commented, but If you don't get the gist
email me and I'll give you some more help.

Later............

- -------------------------------------------------------------------
Chris Rudolph, Senior Engineer,
Technology Works.
Motion Works International.

Internet:  [e-mail]
AppleLink: D2276 ( Subject: Attn: Chris Rudolph )
- -------------------------------------------------------------------

---------------------------

>From [e-mail] (Peter Steele)
Subject: Question for Thread Manager gurus
Date: Thu, 26 Jan 1995 15:23:07 GMT
Organization: Entia Technology Limited

I'm having a problem getting the Thread Manager to work properly with
pre-emptive threads. I'm working on an LC630 with Symantec 7.04 and
System 7.5.

What happens is that pre-emption works in my test program for one run
only. Subsequent runs will just execute in sequence instead of
automatically switching between the pre-emptive threads. This happens
within the Symantec environment as well as in a stand-alone
application. If I restart my Mac, then my test program will work for
one run again. After this run, pre-emption stops again. I tried
restarting without any inits and the same thing happens.

If anyone has an idea about what is happening, please let me know.
Also, if you know of any further thread manager documentation or
sources I'd love to hear about them. I still haven't found out how to
change the timeslice for pre-emptive threads, or whether you can do
this at all.

Thanks for any help you can give me!

Sean Webb
Entia Technology
Halifax, N.S., Canada

--
Peter Steele         Director of R&D         Entia Technology Ltd
5212 Sackville Street, First Floor, Halifax, NS, Canada   B3J 1K6
Tel: [phone]   Fax: [phone]   Email: [e-mail]
Disclaimer: Consider me disclaimed
Cute quote: The best way to predict the future is to invent it.

+++++++++++++++++++++++++++

>From [e-mail] (Robert J. Vaessen)
Date: Fri, 27 Jan 1995 06:06:33 -0500
Organization: Horizon Software

In article <[e-mail]>,
[e-mail] (Peter Steele) wrote:

> I'm having a problem getting the Thread Manager to work properly with
> pre-emptive threads. I'm working on an LC630 with Symantec 7.04 and
> System 7.5.

I have had the same experience and have spoken with others who also have had it.
After a reboot the first application to run works. After that the Thread
Manager is "hosed". Apparantly Apple has a bug to correct.

--
Robert Vaessen
Horizon Software     2222 Greenway Ave     Charlotte, NC   USA  28204
Tel: [phone]    Email: [e-mail]
"Where ever you go, there you are"

+++++++++++++++++++++++++++

>From [e-mail] (Fabrizio Oddone)
Date: Fri, 10 Feb 1995 14:33:14 +0100
Organization: Politecnico di Torino - Italy

In article <[e-mail]>,
[e-mail] (Peter Steele) wrote:

> What happens is that pre-emption works in my test program for one run
> only. Subsequent runs will just execute in sequence instead of
> automatically switching between the pre-emptive threads. This happens
> within the Symantec environment as well as in a stand-alone
> application. If I restart my Mac, then my test program will work for
> one run again. After this run, pre-emption stops again. I tried
> restarting without any inits and the same thing happens.
>
> If anyone has an idea about what is happening, please let me know.
> Also, if you know of any further thread manager documentation or
> sources I'd love to hear about them. I still haven't found out how to
> change the timeslice for pre-emptive threads, or whether you can do
> this at all.

This is a "known" bug in the Thread Manager (see the docs inside my Disk
Charmer application). Both in TM 2.0.1 and System 7.5.
I e-mailed the Apple engineers working on TM, and they told me that the
next System Update would fix this.
I think you cannot control timeslices or priority.
I heard that the abovementioned System Update is imminent...

--
 Fabrizio Oddone
[e-mail]

---------------------------

End of C.S.M.P. Digest
**********************